3. Planning Message Routing to the Organization Perimeter
In Exchange Server 2010, connectors are classified in the following ways:
These types of
connectors can be configured on Hub Transport and Edge Transport
servers. Connectors can be configured using the Exchange Management
Console, but many more details are available when using the Exchange
Management Shell.
Send and Receive
connectors always use SMTP as their message protocol. Foreign or
Delivery Agent connectors use other message protocols, such as X.400,
to transmit messages.
3.1. Configuring Send Connectors
A Send connector is a
connector that transmits a message to the Exchange organization
perimeter using SMTP as the communication protocol. Thus by default it
sends the message using TCP port 25. You use Send connectors to configure how your messages leave the organization. Send connectors allow you to do the following:
Set one or more source Hub Transport server(s) that the connector uses to deliver messages.
Configure one or more dedicated address space(s) for the connector.
Decide where to route the messages (by using a smart host or just using DNS MX record resolution).
Here's what you should consider when planning Send connectors:
Hub Transport servers communicate automatically with each other—you do not need Send connectors for internal communication. Nor should you try to configure internal routing with send connectors because you could cause internal routing issues.
If
you don't use Edge Transport servers as Internet smart-relay hosts, you
should include a Send connector with the SMTP:* address space pointing
to the network connection point to the Internet or to a smart host that
is able to send messages to the Internet.
For organizational internal
message re-routing meaning where you have other SMTP systems inside
your company, you should add the address spaces to the Send
connectors. Whether you create one connector for many partners or one
connector per partner depends on whether you want to manage the
connectors using DNS with MX-records or using smart hosts. Also
consider the management aspect when deciding on one or more connectors.
You can put a scope
on the Send connector to prevent other Active Directory sites from
using it. However, don't forget that a connector with scoped address
space should not be located in the same site as the alternate
least-cost route connector with non-scoped address space. Thus you also
should not configure a scoped address space at Hub sites.
|
Todd Luttinen
Principal Program Manager, Microsoft Corp, Redmond
If you put a scope (an assigned
address space) on a Send or Foreign connector, you prevent Hub
Transport servers located in other Active Directory sites from seeing
it in their local routing tables. Because these transport servers will
not see the connector and its associated scoped address space, they are
prevented from using the scoped address space and associated connector
to compute least-cost routes for external recipient delivery.
However, you need to
consider that the routing calculation is done not only at the source
Hub Transport, but also at every Hub Transport the message is forwarded
to. It will be checked against the local routing table of each Hub
Transport server to find the optimum connector based on least cost and
maximum message size. If one Hub Transport along the way includes a
scoped connector that is more suitable for the message to follow, it
will use it.
For example, assume you're in the Site-Fresno of the Litware Exchange organization. The Site-Fresno has two Send
connectors: one to the Internet with SMTP:*, and one connector with a
Scope to Partners with SMTP:Partners.com. You now send a message from
Site-Berlin to the Internet, which automatically uses Site-Fresno to
forward the message to the Internet. The message will see the scoped
Send connector and use the Partners connector to deliver the message.
The best way to prevent this from happening is not to use scoped Send
connectors in Hub sites or sites where all messages are sent through.
|
3.1.1. Send Connectors and Internet Message Delivery
If you consider using Send connectors that deliver messages to the Internet, you have the following two possibilities to resolve the domains used in recipient addresses:
Using a smart host to deliver the messages to the Internet (the most common scenario when you do not use Edge Transport servers in your organization).
Using DNS MX records to resolve Internet addresses on your own when using an Edge Transport server.
Note: Microsoft
does not recommend connecting a Hub Transport server directly to the
Internet. Thus it is best practice to install a smart host between the
Internet and your Exchange organization.
When using DNS to
resolve message addresses, Exchange queries an external DNS to find the
DNS records required for message delivery. The DNS servers are queried
for the following information:
Mail exchange (MX) records
The MX record contains one or more fully qualified domain names (FQDNs)
of the server that are responsible for accepting messages for the
domain and a preference value. The lowest preference value is always
selected first. To optimize fault tolerance, most organizations use
multiple messaging servers and multiple MX records that have different preference values. If one server fails, the other is used because of the higher preference value.
Address (A) records Every server that has an MX record also has an A record assigned to it. The A record includes the IP address of the server.
|
Ross Smith IV
Senior Program Manager, Exchange Server Product Group, Microsoft Corporation
There are many
different ways to deploy MX records for controlling inbound Internet
mail flow. To frame this discussion, consider a customer who has two
physical locations with an ideal configuration that ensures both
locations are used in some fashion for internal and external mail
routing. As a result, there are three possibilities:
For the first possibility, the DNS configuration can be set as follows:
Customer.com MX preference = 10,
mail exchanger = maila.Customer.com
maila.Customer.com A IP1
maila.Customer.com A IP2
...
Customer.com MX preference = 20,
mail exchanger = mailb.Customer.com
mailb.Customer.com A IP3
mailb.Customer.com A IP4
...
With this mechanism, both MX records are provided to the sending SMTP system, but the lowest-cost MX record is utilized first. When the TCP/IP address
of the host is resolved, the DNS name server rotates the address values
that it returns (via a round-robin mechanism). In this way, DNS
guarantees maila.Customer.com hosts are cycled through and used equally
for receiving inbound mail. Using this approach means that you take
control for cycling through the mail systems: you are not at the mercy
of the sender's SMTP implementation and thereby balancing mail volume
efficiency across all of the Edge Transport servers. The first MX
record is associated with SMTP servers in one data center, whereas the
second, higher-cost MX record is associated with SMTP servers in the
second data center.
This configuration can also
be invoked for load-balancing data across physical locations. For
example, maila.Customer.com can be associated to IP addresses in
primary datacenter and IP addresses in second datacenter. The same can
be done for mailb.Customer.com. The end result in this scenario is that
only half of the existing Edge Transport servers are used at any given
time, with an equal distribution of messages between the two data
centers.
Another solution for load balancing across physical locations is to utilize two equal cost MX records:
Customer.com MX preference = 10,
mail exchanger = maila.Customer.com
maila.Customer.com A IP1
maila.Customer.com A IP2
...
Customer.com MX preference = 10,
mail exchanger = mailb.Customer.com
mailb.Customer.com A IP3
mailb.Customer.com A IP4
...
The difference here is that maila.Customer.com is associated to IP addresses
in one datacenter, whereas mailb.Customer.com is associated to IP
addresses in the other data center. Although this solution cannot
guarantee an equal distribution of messages between datacenters, it can guarantee an equal distribution of messages for a particular MX record.
The third possibility is to utilize a single MX record:
Customer.com MX preference = 10,
mail exchanger = maila.Customer.com
maila.Customer.com A IP1
maila.Customer.com A IP2
maila.Customer.com A IP3
maila.Customer.com A IP4
...
With this
configuration, all Edge Transport servers in both datacenters are
associated to the MX record. This configuration utilizes all SMTP
servers and ensures an equal distribution of messages between all of
the SMTP servers in both datacenters. If the customer's goal is to have
mail flow come into either datacenter, this is the best configuration
option. However, if the customer's goal is to ensure that mail flow is
controlled in terms of datacenter usage, the first scenario is the best
configuration option.
|
3.1.2. Send Connectors in Fabrikam Scenario
If you implement Edge Transport servers, you do not need to create additional Send
connectors by default because they are all created using a default
configuration. However, as in the Fabrikam scenario that uses smart
host servers to send messages to the Internet, you need to create a
Send connector so that your Exchange servers are able to send messages
to the Internet.
For example,
assume you're the Fabrikam administrator and you need to create a Send
connector to your smart host including the SMTP:* address space. The
connector needs to be configured on the Hub Transport server
Fresno-HT01. Here's the cmdlet that would create the Send connector to
the smart host:
New-SendConnector -Name 'To Internet' -Usage 'Internet' -AddressSpaces 'SMTP:*;1'
-IsScopedConnector $false -DNSRoutingEnabled $false -SmartHosts 'smarthost
.fabrikam.com' -SmartHostAuthMechanism 'None' -UseExternalDNSServersEnabled $false
-SourceTransportServers 'FRESNO-HT01'
Fabrikam might create additional Send connectors for the following reasons:
They have a dedicated Partner WAN link that they would like to use to send messages between both companies.
They have an internal
SMTP server that shares the same address space, so they forward all
messages not resolved by the Exchange organization to that SMTP server.
3.1.3. Send Connector Parameters
Many parameters are available to configure Send connectors. Table 5 provides an overview of the most important parameters, what they are used for, and when you need to consider changing them.
Table 5. Set-SendConnector Parameters
| PARAMETER | DESCRIPTION | WHEN SHOULD IT BE CHANGED? |
|---|
| AddressSpaces | Address space(s) are processed by this connector. | To configure target Address Spaces (for example, "SMTP:*" to send all messages through it). |
| AuthenticationCredential | Defines authentication credentials (user name and password). | When your target connector requires authentication. |
| Comment | Defines comments for this connector. | To provide additional details regarding the purpose of the connector. |
| ConnectedDomains | For Exchange 2003 support, includes connected routing groups. | Cannot be changed. |
| ConnectionInactivityTimeOut | Times when to disconnect an idle connector. | Can be changed to reduce the amount of idle connections. |
| DNSRoutingEnabled | Specifies that the connector will use the local DNS Server to resolve the message. | If you don't have a smart host to relay messages, you need to use this option. |
| DomainSecureEnabled | Configures Domain Security using TLS on this connector. | Enable if you want to support Domain Security to partners or others. |
| Enabled | Enables or disables this connector. | Only if you want to disable the connector. Remember, disabling connectors causes issues with Exchange 2003. |
| ForceHELO | You can configure the server to respond to SMTP connections with HELO rather than EHLO. | You need to change this if your target SMTP server requires the HELO command to be sent. |
| Fqdn | Specifies the FQDN that will be provided after EHLO or HELO. | If the target server requires a specific response after EHLO, you can change it here. |
| HomeMTA | For Exchange 2003 support, includes Microsoft MTA. | Cannot be changed. |
| HomeMtaServerId | Transport Server on which the connector was created. | Cannot be changed. |
| Identity | GUID of connector. | Cannot be changed. |
| IgnoreSTARTTLS | Configures whether the connector uses TLS if offered. | Change it only if you want to disable TLS for this connector. |
| IsScopedConnector | Defines the scope of this connector. | When changed, the connector can only be used by Hub Transport servers in the same site. |
| IsSmtpConnector | Specifies SMTP as protocol. | Cannot be changed. |
| LinkedReceiveConnector | Forces all messages received by a specified Receive connector to be sent over this connector. | Useful if you want to forward all messages for inspection, such as to a third-party anti-spam service. |
| MaxMessageSize | Maximum message size the connector can send. | Configure a specific message size. |
| Name | Name of the connector. | Change the name. |
| Port | Port number to communicate. | If the send connector uses a port other than port 25. |
| ProtocolLoggingLevel | Configures the logging level for SMTP. | Enable verbose logging for troubleshooting connector issues. |
| RequireTLS | Configures that communication must be encrypted using TLS. | Change this only if you're sure that all target servers support TLS. |
| SmartHostAuthMechanism | Defines the authentication mechanism when using a smart host. | If the smart host requires specific authentication, this option needs to be configured accordingly. |
| SmartHosts | Defines IP address, MX records, or A record(s) of any smart host(s) used. | Configure a smart host if you want to forward all messages to the specified server(s). |
| SmartHostsString | Includes the SmartHosts parameter as a string. | Cannot be changed. |
| SmtpMaxMessagesPerConnection | Maximum messages this connector can send per connection. | If the target connector is configured to receive more messages, it can be changed accordingly. |
| SourceIPAddress | Specifies a specific IP address that will be shown to the target connector. | If
your local server has multiple IP addresses and the target server
requires one specific IP address, such as for authorization. |
| SourceRoutingGroup | Routing group the connector belongs to. Only used for backward compatibility with Exchange 2003. | Cannot be changed. |
| SourceTransportServers | Specifies the names of the Transport servers that can use this connector. | For redundancy, you should always add all Hub Transport servers that can use it. |
| UseExternalDNSServers Enabled | Uses DNS server(s) that were specified in Set-TransportServer. | If this connector needs to use another DNS server that is configured locally. |
3.2. Configuring Receive Connectors
To receive inbound SMTP
messages from external domains, you need a Receive connector in
Exchange 2010. This connector acts as an inbound connection point that
you can configure to accept connections based on IP address ranges and
port numbers. You can configure a Receive connector on a per-server
scope only. Thus, if you want to have many servers receive messages,
you need to configure one connector for every server.
Receive
connectors have configuration limits that you can set, such as number
of active connection, maximum message size, or maximum recipients per message. You also can set the type of authentication required to send a message.
By default two Receive
connectors are created on every Hub Transport server that are almost
identical, but with one important difference: You configure the Client
<servername> Receive connector to listen on port 587 rather than
on port 25. As described in RFC 2476, port 587 has been proposed for
use only for message submission from e-mail clients that require
message relay.
Note: A Receive connector by default only accepts e-mail domains that are defined in Accepted Domains that you can list using the Get-AcceptedDomain cmdlet. All other domains are considered Message Relaying and need additional permissions to be processed.
What does this have to do with planning? Well, you should configure Receive connectors at every Hub Transport server serving an external inbound connection. Also, you should have dedicated Receive
connectors for your applications that want to send messages so that you
understand how many applications send messages to your system.
3.2.1. Receive Connectors in Fabrikam Scenario
Which Receive
connectors do you need for a specific environment like the Fabrikam
Scenario? As mentioned, Fabrikam has Apple Macintosh clients that use
IMAP4 to receive their messages from the CAS server. However, POP3 and
IMAP4 need to use SMTP to send messages. They also use a smart host to
send and receive messages from the Internet.
To ease management, you create new Receive
connectors (instead of using the default connectors) enforcing
authentication as well as encrypted client-to-server communication
using TLS. For your sample scenario the following Receive connectors should be created:
You can create an
example Receive connector configuration for the IP range of 10.10.0.1
(Subnet 255.255.255.0), enforcing TLS encryption, and only allowing
Exchange mailbox users and Exchange servers to use it on the local
Exchange server by using the following cmdlet:
New-ReceiveConnector -Name "Client SMTP TLS" -Bindings "0.0.0.0:25" -AuthMechanism
"Tls, BasicAuth, BasicAuthRequireTLS, ExchangeServer" -PermissionGroups "ExchangeUsers,
ExchangeServers" -RemoteIPRanges 10.10.0.1-10.10.0.255
Note: The most important task after creating a Receive connector is to test its functionality. You can use Telnet <servername> 25
to connect to the Receive connector or use a client to check it.
Remember that the Telnet Client is now a Windows Server 2008 feature
that is not installed by default.
Additional reasons to create Receive connectors are as follows:
To receive messages from an Internet smart host (if you do not use Edge Transport servers to receive messages from the Internet)
If you need to turn off user authentication for specific clients based on IP address
To allow relaying of messages accepted from SMTP servers
For using a dedicated Receive connector for Domain Security on Edge Transport servers
|
Christian Schindler
Senior Consultant, NTx BackOffice Consulting Group, Austria
In previous versions of Exchange Server you enabled relaying
by simply activating a check box on the Properties page of an SMTP
Virtual Server and adding IP Addresses to a list. In Exchange Server
2007 and 2010 this has changed a bit.
First, the SMTP Virtual
Server no longer exists—the replacement is a Receive connector. Second,
there's no check box to simply activate relaying—we have to use
permissions in Active Directory to allow for relaying. However, we
still need to specify which IP Addresses are allowed to relay.
To enable Relaying on an
Exchange Server 2010 Hub Transport Server, you create a new Receive
connector. Then you specify the server's IP addresses that are allowed
to relay by configuring the RemoteIPRanges parameter of the Receive
connector. As a final step, you need to set permissions on the Send
connector to grant Anonymous the right to relay. This can be done
either via ADSIEDIT or by using the following Windows PowerShell
command:
Get-ReceiveConnector <Name of Connector> | Add-ADPermission -User "NT
AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-
Recipient"
During a migration from
previous version of Exchange, you need to create relaying connectors
with the same settings as on the original servers. Getting the list of
allowed server IP addresses is particularly important. When you have a
large list, it is crucial to automate this step to avoid human errors.
This can easily be done by using the ExIpSecurity.exe
Tool, which can be downloaded from the Microsoft Download Center. It
allows you to export the list of allowed IP addresses to a file. The
file can easily be used in a Windows PowerShell script to create the
necessary Receive connectors in Exchange Server 2010.
|
3.2.2. Creating a Linked Connector
A linked connector is a Receive connector that is linked to a Send connector. For linked
connectors, the regular routing logic that is based on the destination
domain is overridden. All messages that are received by the Receive
connector are forwarded to the linked Send connector.
You can see an example of a
linked connector in the Fabrikam scenario: they want to outsource their
anti-spam and antivirus service. They thus create a linked connector at
the Internet message entry point in their Exchange organization and
forward all messages to a third-party service provider for scanning.
Then they receive the message back from the service provider using a
dedicated Receive connector that is no longer linked.
The following list describes the requirements that you must meet to create linked connectors:
Only one Receive connector can be linked to one Send connector.
The Receive connector must exist before it can be linked to a Send connector.
A linked Send connector must route messages to a smart host.
You can only link a Receive connector to an existing Send connector by using the LinkedReceiveConnector parameter in the Set-SendConnector cmdlet.
3.2.3. Receive Connector Parameters
Table 6 provides an overview of the most important parameters for Receive connectors. However, many more parameters can be configured on Receive connectors. You do not need to know them by heart, but should remember what options are available if you need them.
Table 6. Set-ReceiveConnector Parameters
| PARAMETER | DESCRIPTION | WHEN SHOULD IT BE CHANGED? |
|---|
| AuthMechanism | Defines the advertised and accepted authentication mechanisms. | If you want to enforce TLS encryption or a specific Authentication type, you need to configure it here. |
| Banner | The Banner parameter specifies an override to the default SMTP 220 banner. | If you like to respond in a customized way to requests, this can be changed. |
| BinaryMimeEnabled | Specifies whether the BINARYMIME EHLO keyword is advertised and is available for use. | |
| Bindings | Specifies the local IP and port number the connector listens to. | If you change the bindings to a different port, make sure that all sending servers also use the same port. |
| ChunkingEnabled | Chunking enables large message bodies to be relayed by the remote server to the Receive connector in multiple, smaller chunks. |
|
| DeliveryStatusNotificationEnabled | Specifies
whether the delivery status notification (DSN) EHLO keyword is
advertised in the EHLO response to the remote server and is available
for use. |
|
| DomainSecureEnabled | Enables or disables Domain Security (also known as mutual TLS). | Domain Security is normally only enabled on Edge Transport servers to securely communicate over the Internet. |
| EightBitMimeEnabled | Enables or disables 8-bit MIME. | MIME 8-bit should only be disabled if you face issues when receiving binary data, such as attachments. |
| EnhancedStatusCodesEnabled | Enables or disables enhanced Status Codes. |
|
| LongAddressesEnabled | Enables the Receive connector to accept long X.400 e-mail addresses. |
|
| OrarEnabled | Specifies whether to enable the Originator Requested Alternate Recipient (ORAR). |
|
| SuppressXAnonymousTls | Defines whether standard TLS encryption for incoming connections is available. | If you use WOC devices to optimize WAN links, you want to change the default setting to turn off TLS. |
| AdvertiseClientSettings | Defines
whether the SMTP server name, port number, and authentication settings
are displayed in the Outlook Web App About page, which is accessed from
the Help menu. | Especially in CAS arrays you should enable this to be able to identify the CAS server the client is connected to. |
| Enabled | Enables or disables this connector. |
|
| ConnectionTimeout | Specifies the maximum time that a connection can remain open, even if the connection is actively transmitting data. | If you have SMTP clients that transmit large amounts of data over a slow link, consider increasing this setting. |
| ConnectionInactivityTimeout | Defines the maximum amount of idle time before a connection is closed. | Change this setting if you want to fine-tune message throttling options. |
| MessageRateLimit | Defines the maximum number of messages that can be sent by a single client IP address per minute. | Change this setting if you want to fine-tune message throttling options. |
| MessageRateSource | Specifies how the message submission rate is calculated (None, IPAddress, User, All). |
|
| MaxInboundConnection | Defines the maximum number of inbound connections that this Receive connector serves at the same time. | Change this setting if you want to fine-tune message throttling options. |
| MaxInboundConnectionPerSource | Defines the maximum number of inbound connections that this Receive connector serves at the same time from a single IP address. | Change this setting if you want to fine-tune message throttling options. |
| MaxHeaderSize | Specifies in bytes the maximum size of the SMTP message header. |
|
| MaxHopCount | Specifies the maximum number of hops that a message can take before the message is rejected by the Receive connector. |
|
| MaxLocalHopCount | Specifies
the maximum number of local hops (for example, internal Exchange
servers) that a message can take before the message is rejected by the
connector. | For large organizations, you might need to increase the value if you configure many Hub sites for Exchange,. |
| MaxLogonFailures | Number of logon failures that the Receive connector retries before closing the connection. |
|
| MaxMessageSize | Specifies the maximum size of a message. |
|
| MaxProtocolErrors | Specifies the maximum number of SMTP protocol errors before closing the connection. | Change this setting if you want to fine-tune message throttling options. |
| MaxRecipientsPerMessage | Defines how many recipients a single message can address. |
|
| Name | Administrator-defined name of connector. |
|
| PermissionGroups | Defines the groups or roles that can submit messages to the Receive connector: ExchangeUsers, ExchangeLegacyServers, and so on. |
|
| PipeliningEnabled | Enables or disables Pipelining in SMTP to send requests without awaiting a response. |
|
| ProtocolLoggingLevel | Specifies whether to enable protocol logging for the specified Receive connector. | If you have trouble with the connector, enable Verbose logging to see the full SMTP communication in the log directory. |
| RemoteIPRanges | Defines the remote IP addresses that can use this connector. |
|
| RequireEHLODomain | Specifies whether the remote computer must provide a domain name in the EHLO handshake. |
|
| RequireTLS | Configured if a session requires TLS encryption. | Set this to $true if you want to make sure the communication is encrypted. |
| EnableAuthGSSAPI | Specifies
how to control the advertisement of the Generic Security Services
application programming interface (GSSAPI) authentication method when
Integrated Windows authentication is enabled on this connector. |
|
| SizeEnabled | Specifies whether the SIZE SMTP extension is enabled. | You can change this on Edge Transport servers to advertise the maximum message size that is allowed in EHLO banner. |
| TarpitInterval | Specifies the period of time to delay an SMTP response to a remote server that Exchange determines may be abusing the connection. Authenticated connections are never delayed in this manner. | Change this setting if you want to fine-tune message throttling options for anonymous senders. |
| MaxAcknowledgementDelay | Specifies
the time a Transport Server waits when sending a message to a server
that doesn't support shadow redundancy before sending the
acknowledgment. |
|
3.3. Configuring Delivery Agent Connectors
A delivery
agent connector is similar to the Foreign connector in that it is used
to route messages to foreign systems that don't use the SMTP protocol,
such as an X.400-based messaging system that does not have an SMTP
connector available. When a message is routed to a delivery agent
connector, the associated agent performs content conversion and message
delivery.
The advantage of using
the delivery agent connector is that the agent already performs content
conversation and message delivery—thus there is no need to store
messages on the file system in a Drop or Pickup directory as required
by the Foreign connector.
The delivery agent functions as follows:
It establishes a connection to the foreign system.
It retrieves messages from the Hub Transport's remote delivery queues.
It delivers the message to the foreign system and receives an acknowledgment for each successful delivery.
It retrieves waiting messages from the foreign system.
In comparison to the
Foreign connector, where you place the message only in a drop directory
and wait until it is processed, a delivery agent connector acknowledges
the message delivery to the foreign system and thus allows service
level agreement (SLA) analysis as you can track message latency to the
foreign system. You also can use Exchange's Queue Viewer to verify message delivery, which is not the case with Foreign connectors.
Note: While
the Foreign connector architecture remains in Microsoft Exchange Server
2010, Microsoft recommends using delivery agents for routing messages
to non-SMTP systems whenever possible.
Exchange Server 2010 by default only comes with one Delivery Agent Connector: the Text Messaging Delivery Agent connector. This connector is used to route messages to mobile phones using the Address Space MOBILE:*, as shown in Figure 6.
Microsoft's intention is to
replace connectors with other non-SMTP mail systems that were written
with the old Exchange 2003 SDK (Foreign connectors) with new Delivery
Agent connectors written using the Exchange 2010 SDK. Therefore, you
would buy a new Delivery Agent connector for a foreign e-mail system
such as Lotus Notes or Novell GroupWise from a third-party developer or
you'd build your own connector if you had the time, patience, and
expertise.
You use the Set-DeliveryAgentConnector cmdlet to configure the connector; you get information about the connector's configuration using the Get-DeliveryAgentConnector cmdlet.
3.4. Configuring Foreign Connectors
A Foreign connector is a
connector that does not use the SMTP protocol for communication and was
implemented with Exchange Server 2003 SDK. Even though it is not the
recommended way to connect Exchange to a foreign system because
Exchange 2010 implements Delivery
Agent connectors to handle messages to foreign systems in a more
sophisticated way, it still exists and can be used for existing
third-party connectors.
To be able to communicate with third-party
systems, the Foreign connector uses a Drop directory to send messages
to the foreign gateway servers. Foreign gateway servers can send
messages to Exchange Server 2010 by using the Replay directory found on
every Hub Transport server in <Exchange_Installation_Path>\TransportRoles\Replay.
Every Foreign connector has an address space assigned to it that includes the following elements:
Connector Scope Hub Transport servers that can use the connector
AddressSpaceType For example, FAX or X.400
AddressSpace A valid address space for the AddressSpaceType
AddressSpaceCost Routing costs
Planning for Foreign connectors is a key task when doing an Exchange Server 2010 design. You should consider the following in your plan:
Plan for fault tolerance when implementing Foreign connectors; make sure the Drop directory is available.
Make sure the third-party
connector fully supports Exchange Server 2010 before you move it over
to the Exchange server, especially if you are in an environment where
Exchange 2003 still exists. Alternatively, you can simply keep an
Exchange 2003 server in place to host the old connector until you can
either replace it with a new Delivery Agent connector or work out how
to route messages to the other e-mail system with SMTP.
